Important safety aims for developments in electronic closed-loop control systems, particularly in automobile electronics, stem from the effects in the event of malfunctions in these systems. Critical effects in the event of malfunctions or failures may be locking of the wheels of a vehicle or excessive, unwanted braking torque on the rear axle with the possible consequence of destabilization of the motor vehicle. By way of example, functions that comprise autonomous acceleration can result in destabilization, particularly for severe torque increases when electric motors are used as drive units. For this, ISO 26262, which is incorporated by reference, provides general focusing for the safety aims of excessive unwanted effects or undersized or negative unwanted effects being avoided, which is why most systems need to protect a flexible corridor for their safety concepts. The tolerable, unwanted torque is situated within this corridor, in which the vehicle needs to be able to be safely controlled in all admissible driving situations. Above this corridor, there are dangerous acceleration effects, for example, while below there is locking of the axles or wheels. The form of the corridor is essentially dependent on the vehicle specifications, such as axle spacing, weight, center of gravity and further parameters, such as speed, road condition, lateral acceleration, curve radius, etc. Such a corridor even exists for stable driving straight ahead.
The upper and lower limits need to be stipulated in accordance with the safety requirements (e.g. ASIL) of the respective function and the vehicle specifics and also the further parameters. The possible erroneous triggering of an undersized or excessive unwanted torque by a driver assistance function that influences the acceleration of the vehicle can require this function to be grouped into a high safety requirement level, such as ASIL D. This means that an error in this function can immediately result in a risk to persons.
According to IEC 61508, which is incorporated by reference, the safety aim of transferring a system to a safe state is pursued, inter alia, which frequently results in a switch to a zero-current state in the event of an error occurring. This is intended to limit a potential risk to persons. For this reason, a plurality of safety aims exist, particularly according to ISO 26262, wherein the safe state is a state that does not present any risk to persons but does not necessarily lead to a zero-current or zero-energy state.
As a fundamental safety concept for engine, transmission, steering and other chassis control systems, DE 10 2006 056 668 A1, which is incorporated by reference, describes a method for ensuring or maintaining the operation of a complex safety-critical overall vehicle closed-loop and/or open-loop control system in the event of the occurrence of errors, malfunctions or other events that have an influence on the availability of subfunctions. For this, modes of operation are defined for the necessary system components, with the modes of operation that are affected by the errors that have occurred being ascertained in the event of error. From the modes of operation that are still available, a selection is then made, in view of the most extensive possible availability of the overall system, and hence the performance of the system is degraded in stages.
Particularly for engine management systems in electromobility, it is necessary to consider implementations up to the highest safety requirement level (e.g. ASIL D). Unwanted effects, as are described above, are considered particularly in the case of multilevel software architectures for safety-relevant motor vehicle control systems. Essential safety functions are accordingly implemented by means of appropriate design of the hardware and software and the interaction thereof, and particularly the independence of the safety functions that is required by ASIL, e.g. for data communication, is achieved by means of data encryption. If it is no longer possible to decrypt the key at the receiver, a disconnection path, such as an intelligent watchdog (window watchdog), is used to disconnect the communication or the entire system.
Modern generations of (multicore) microcontrollers have inherently known safety mechanisms for the entire hardware, with the redundant processors frequently operating in a synchronous or asynchronous lockstep mode, so that single, multiple or brief errors can be controlled. A microcontroller within the context of this description is also understood to mean microprocessors, microcontroller systems and microprocessor systems, which have at least one processor and are able to capture and output signals via peripheral functions.
A time delay in the execution of tasks between redundant processors allows errors to be tolerated within a safety time (e.g. less than 1 ms) on account of integrated hardware safety mechanisms, since these errors are prevented from causing a potentially dangerous situation by at least one safety mechanism. By way of example, the safety mechanism could be data correction that corrects data identified as incorrect and uses said corrected data for further processing.
The communication by the hardware, such as by a microcontroller with its peripherals, can be protected against different types of error by error correction methods (ECC), error detection methods (EDC) and/or end-to-end data encryption (E2E). EDC is important for controlling the error correction, so that tolerances or reactions can be adapted upon the occurrence of a plurality of and/or transient errors. Digital output values from peripheral units, such as analog-to-digital converters, can be protected by means of EDC, for example, the values of the analog input variables being protected by means of two independent potential bands separated by an undefined range. By way of example, values greater than 4.5 V may correspond to a high level and values less than 0.5 V may correspond to a low level. The validity registers are then coupled to the digital output values during the analog-to-digital conversion as data encryption or a data signature.
For motor vehicle controllers, there is increasing standardization of the software architecture or use of runtime environments (RTE) in order to improve the portability, reusability and safety of software modules, inter alia, and ultimately also to save development costs. For the application software of a motor vehicle controller, a standardized environment is therefore provided that is no longer directly influenced by technical influences of the microcontroller. For architectural analysis for the purpose of establishing all the actually possible error influences of a microcontroller on the software implemented thereon, it is essentially necessary to check every property of the microcontroller. In the event of a change to another microcontroller type or if the manufacturer of the microcontroller changes the production technique or materials used, this needs to be taken into consideration. The advantage of using standardized software architecture is therefore that no or only small adaptations to this application software need to be made in the event of changes to the hardware.
A further safety principle according to the prior art is explained below using the example of the standardized software architecture AutoSar® (AUTomotive Open System ARchitecture®). Version 4 of AutoSar® specifies E2E safety for a communication channel from basic software to a level of a runtime environment (RTE). At a software level that is based on a microcontroller abstraction level, the crude information that is present from the peripherals as input signals is encrypted and, following transfer of the encrypted data by the software levels, decryption takes place in the region of the RTE. The application software, which is superordinate to the RTE as a further level, can then use these data for further processing. Thus, software-based E2E data encryption by AutoSar® takes place, with particularly the hardware software interface not being protected. However, no safety-relevant influence is permitted to take place on software for function monitoring, communication channels of the peripherals, degradation software or further safety software. The division of the control functions and the function monitoring and also the hardware or system protection, for example in the basic software, into different software levels allows possible error propagations to be reduced and hence error cascades, such as in the case of separate controllers, to be avoided or interrupted.
Basic errors that affect the application software from the hardware may be data that are corrupted by a wide variety of causes or that are generated incorrectly, for example. In addition, it is possible for data not to be made available to a software process in good time as a result of errors in the hardware.